The Internet is a vast computer network comprised of a wide variety of disparate computing devices, interconnected by various connection media, which communicate using the transmission control protocol/Internet protocol (“TCP/IP”) set of communication protocols. In recent years, it has become increasingly commonplace for commercial enterprises such as corporations to interconnect with the Internet using a computer system commonly referred to as a web server. While a web server typically maintains publicly available content, oftentimes, it will also maintain content for which access is limited to authorized users. For example, a service provider may provide confidential account information to its customers on-line but would prevent an unrelated third party from being able to review the information. To minimize the security issues raised by allowing customers to access confidential information over an unsecured network, it is oftentimes recommended that the service provider secure the confidential information using an authentication/authorization process. Authentication is the process of verifying a user's identity while authorization is the process of restricting the resources that the user can access after the authentication of the user has been accepted.
A wide variety of solutions to the problem of securing all or a portion of a web site or other computer network have been proposed. Many such solutions require the user to provide information which is used to initiate authentication and/or authorization processes. As the Internet is generally considered to be an unsecured public network, security systems which protect restricted resources of a web site often utilize a tiered security process in which the data used to authenticate and/or authorize users is maintained within a private network, coupled to the web server, but also protected from unauthorized accesses by a firewall. One such tiered security process, commercially known as GetAccess, is manufactured by Entrust, Inc. of Santa Clara, Calif.
A deficiency in the GetAccess tiered security process, as well as other tiered and/or untiered security processes, is that they only provide a minimal amount of information to the service provider regarding authentication and/or authorization failures. When a security process fails, for example, when the security process denies access to an authorized user, the system must be carefully examined to determine the cause of the failure. Typically, existing security processes only report that a particular user's authentication and/or authorization failed. Unfortunately, such a limited amount of information is not particularly useful when attempting to determine the cause of a failure, particularly when the failed security process involves plural servers, databases and communication links, any one of which could be the cause of the failure.
The Common Object Request Broker (“CORBA”) specifies a system which provides transparent interoperability between objects in a heterogeneous, distributed environment. Its design is based upon the Object Management Group (“OMG”) object model. The OMG object model defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way. In this model, clients request services from objects through a standardized interface defined in the OMG Interface Definition Language (“IDL”). A client accesses a targeted object by issuing a request to that object. The request is an event, and it carries information including an operation, the object reference of the service provider and any actual parameters.
The central component of CORBA is the object request broker (“ORB”). The ORB encompasses the entire communication infrastructure necessary to identify and locate targeted objects, handle connection management and deliver data. The ORB core is that part of the ORB that provides the basic representation of objects and the communication of requests thereto. Thus, the basic functionality provided by the ORB core consists of passing the requests from clients to the object implementations on which they are invoked. In order to make a request, the client can communicate with the ORB core through the IDL stub or through the dynamic invocation interface (“DII”). The IDL stub represents the mapping between the implementation language for the client and the ORB core. Thus, the client can be written in any language for which the ORB core supports the mapping thereof. The ORB core then transfers the request to the object implementation which receives the request as an up-call through either an IDL skeleton or a dynamic skeleton.
For the aforementioned reasons, CORBA is a popular standard for developing distributed applications. Interceptors are an optional extension to the ORB. An interceptor is interposed in either the invocation and/or response paths between a client and a targeted object and is responsible for the execution of one or more ORB services. Typically, the ORB will invoke an interceptor upon receiving a particular request for services from a targeted object. The interceptor will then perform one or more actions, including invoking other objects. In this manner, interceptors provide a way to add portable ORB services to a CORBA compliant object system.
By using a CORBA-compliant interceptor to intercept each message to/from a network-level service residing on a computer system forming part of the network and then logging selected information for each intercepted message, this invention provides a tool by which a network administrator or other service technician may readily identify and/or rectify problems with the network-level service.